home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19990422-19990725
/
000103_news@watsun.cc.columbia.edu _Wed May 26 17:52:53 1999.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA29573
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 May 1999 17:52:52 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id RAA01302
for kermit.misc@watsun.cc.columbia.edu; Wed, 26 May 1999 17:32:40 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: kermit process hangs around after terminal disconnect
Message-ID: <eYzrHu7mxevb@cc.usu.edu>
Date: 26 May 99 15:27:46 MDT
Organization: Utah State University
To: kermit.misc@watsun.cc.columbia.edu
In article <7ihl1n$asf$1@nnrp1.deja.com>, Mr. Scott <scott_davis@my-deja.com> writes:
>>From the standpoint of the Unix side of the connection everything is
>>perfectly fine. It has not received any data in a long time but there
>>is no requirement that it ever receive any data. Nor has it tried to
>>send any data therefore as far as it is concerned everything
>>is ok
>
> Hmmm, perhaps I had better study the TCP protocol better.
> I thought it was the nature of the TCP protocol to maintain
> a "connected" state through the (invisible to the socket programmer)
> use of some sort of "keepalive" packets. If the keepalive packets
> don't arrive after a time, the connection is deemed lost. That was my
> impression. So although no application data is needed or expected in
> either direction, the lack of keepalive messages should still flag the
> telnetd that the connection is no longer active and therefore notify
> the terminal driver to cleanup the session. Again, that is only my
> impression of how it works. Do you have anything to add?
--------------
Unfortunately or not, TCP has no such facility. The keepalive
I discussed today is a special feature on some systems that cuts in after
say an hour of inactivity. There is normally no traffic when the apps
have nothing to say, and it is a common misunderstanding that network
connections are like telephone connections (where hanging up breaks
an electrical circuit).
As Jeff tried to explain, what happens after a stack tries to
send and fails is up to that operating system to manage. The stack is
often in the kernel and failure messages are passed up to the application.
What happens next is up to the application, not up to the protocol stack.
Thus they may be ignored up there and programs continue to be active.
Some systems have an overriding inactivity timer, a looong one, which
works on any connection in the manner that no activity will kill the
login process and any available descendents. Many don't have this facility.
Some, say VMS, snoop and notice the communications channel has declared
a no-comms situation and shortly after will kill the login session. But
it takes outgoing traffic to detect this event.
Joe D.